Just a few years ago it was normal to configure network apparatuses using proprietary interfaces, differing across vendors, apparatus types (switches, routers, firewalls, load balancers, etc.), and even different firmware releases for a same apparatus. Managing heterogeneous multivendor networks of non-marginal scale was (and still is) extremely difficult, and required (and still requires) a huge expertise.
“OpenFlow” emerged very recently, i.e. in 2008, as an attempt to change this situation. OpenFlow's breakthrough was the identification of a vendor-agnostic programming abstraction for configuring the forwarding behavior of network switching apparatus. Via the OpenFlow Application Programming Interface, in short “API”, network administrators can remotely reconfigure at runtime forwarding tables, probe for flow statistics, and redirect packets not matching any local flow entry towards a network controller for further analysis/processing and for taking relevant decisions; in essence “program” the network from a central control point, clearly separated from the forwarding level.
Today, such vision is called Software Defined Networking, in short “SDN”.
OpenFlow turned to be immediately deployable, thanks to its pragmatic balance between open network programmability and real world vendors' and deployers' needs. Starting from the recognition that several different network devices implement somewhat similar flow tables for a broad range of networking functionalities (L2/L3 forwarding, firewall, NAT, etc.), the authors of OpenFlow proposed an abstract model of a programmable flow table which was amenable to high-performance and low-cost implementations; capable of supporting a broad range of research; and consistent with vendors' need for closed platforms.
Via the OpenFlow “match/action” abstraction, the device programmer can broadly specify a flow via an header matching rule, associate forwarding/processing actions to the matching packets, and access bytes/packet statistics associated to the specified flow.
Almost six years have now passed since the OpenFlow inception, and the latest OpenFlow standard, now at version 1.4, appears way more complex than the initial elegant and simple concept. To fit the real world needs, a huge number of extension (not only the initially foreseen functional ones, such as supplementary actions or more flexible header matching, but also structural ones such as action bundles, multiple pipelined tables, synchronized tables, and many more) were promoted in the course of the standardization process. And new extensions are currently under discussion for the next OpenFlow version.
All this hectic work was not accompanied by any substantial rethinking in the original programmatic abstraction (besides the abandoned Google OpenFlow 2.0 proposal, considered too ambitious and futuristic), so as to properly capture the emerging extensions, simplify their handling, and prevent the emergence of brittle, platform-specific, implementations which may ultimately threaten the original vendor-independency goal of the OpenFlow inventors.